@smarter can you review last commit please?

The observed error was for compile-stdlib Junit test on my machine.

@odersky, I'm not getting the change in 1c7c738. Would you mind providing either example or explanation? Thanks.

@DarkDimius It was something detected and diagnosed by @smarter. Maybe he can give an example. The test case he found was super-complicated though. The patch makes obvious sense; of course the class owner of type parameters needs to be completed before the parameters are type-checked. The only surprising thing is that this is not already always the case, but that sometimes an explicit ensureCompleted is required. @smarter knows better what scenario leads to this.

I observed this when desugaring repeated parameters (but it can happen in a bunch of place in Desugar):

1. In https://github.com/lampepfl/dotty/blob/96fcdd9da51e1febe9e320f774424b5ac3f8ff3d/src/dotty/tools/dotc/ast/Desugar.scala#L880-L885 we construct the untyped tree AppliedTypeTree(ref(seqType), t)) where ref(seqType) is a spliced type tree whose type is a TypeRef to Seq, notice that this does not involve forcing the info of Seq.
2. When typing this AppliedTypeTree, we must first type the type constructor but there's nothing to do since it's a spliced type tree, the info of Seq is still unforced.
3. Then we need to type the argument of the AppliedTypeTree, this requires forcing the info of the corresponding type parameter (Seq$$A).
4. Forcing the info of Seq$$A fails in https://github.com/lampepfl/dotty/blob/96fcdd9da51e1febe9e320f774424b5ac3f8ff3d/src/dotty/tools/dotc/typer/Typer.scala#L854-L867 because the info of Seq is still unforced, so the OriginalSymbol attachment is missing.

So I see two ways to fix this: either make sure in Desugar that we never construct an AppliedTypeTree without forcing the info of the type constructor or changing the definition of ensureCompletions to ensure that, which is what 1c7c738 does and is very similar to what I did locally.

LGTM.